FHIR Server FHIR Server Version n/a

reference

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHOULD	patient+ clinical-status	reference+token

Conformance

Parameter Combination

Types

SHOULD

patient+ clinical-status

reference+token

Search Parameter Requirements (When Used Alone or in Combination):

clinical-status (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.
patient (reference):
The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.

CarePlan

Conformance Expectation: SHOULD

Resource Specific Documentation:

Additional considerations for systems aligning with HL7 Consolidated (C-CDA) Care Plan requirements:

US Core Goal SHOULD be present in CarePlan.goal

US Core Condition SHOULD be present in CarePlan.addresses

Assessment and Plan MAY be included as narrative text

Supported Profiles:

SHALL support: US Core CarePlan Profile

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Client SHALL be capable of fetching a CarePlan resource using: GET [base]/CarePlan/[id]
A Client SHOULD be capable of supporting the following _revincludes: Provenance:target - GET [base]/CarePlan?[parameter=value]&_revinclude=Provenance:target

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHALL	patient+ category	reference+token
SHOULD	patient+ category+ status	reference+token+token
SHOULD	patient+ category+ status+ date	reference+token+token+date
SHOULD	patient+ category+ date	reference+token+date

Conformance

Parameter Combination

Types

SHALL

reference+token

SHOULD

patient+ category+ status

reference+token+token

SHOULD

patient+ category+ status+ date

reference+token+token+date

SHOULD

reference+token+date

Search Parameter Requirements (When Used Alone or in Combination):

category (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.
date (date):
A client SHALL provide a value precise to the second + time offset.

A server SHALL support a value precise to the second + time offset.
patient (reference):
The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.
status (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.

CareTeam

Conformance Expectation: SHOULD

Resource Specific Documentation:

In order to access care team member's names, identifiers, locations, and contact information, the CareTeam profile supports several types of care team participants. They are represented as references to other profiles and include the following four profiles which are marked as must support:

US Core Practitioner Profile

US Core PractitionerRole Profile

US Core Patient Profile

US Core RelatedPerson Profile

Although both US Core Practitioner Profile and US Core PractitionerRole are must support, the server system is not required to support both types of references, but SHALL support at least one of them.

The client application SHALL support all four profile references.

Bacause the US Core PractitionerRole Profile supplies the provider's location and contact information and a reference to the Practitioner, server systems SHOULD reference it instead of the US Core Practitioner Profile.

Servers that support only US Core Practitioner Profile and do not support the US Core PractitionerRole Profile SHALL provide implementation specific guidance how to access a provider’s location and contact information using only the Practitioner resource.

Supported Profiles:

SHALL support: US Core CareTeam Profile

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Client SHALL be capable of fetching a CareTeam resource using: GET [base]/CareTeam/[id]
A Client SHOULD be capable of supporting the following _includes:
- CareTeam:participant:PractitionerRole: GET [base]/CareTeam?[parameter=value]&_include=CareTeam:participant:PractitionerRole
- CareTeam:participant:Practitioner: GET [base]/CareTeam?[parameter=value]&_include=CareTeam:participant:Practitioner
- CareTeam:participant:Patient: GET [base]/CareTeam?[parameter=value]&_include=CareTeam:participant:Patient
- CareTeam:participant:RelatedPerson: GET [base]/CareTeam?[parameter=value]&_include=CareTeam:participant:RelatedPerson
A Client SHOULD be capable of supporting the following _revincludes: Provenance:target - GET [base]/CareTeam?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance	Parameter	Type
SHOULD	role	token

Conformance

Parameter

Type

SHOULD

role

token

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHOULD	patient+ role	reference+token
SHALL	patient+ status	reference+token

Conformance

Parameter Combination

Types

SHOULD

patient+ role

reference+token

SHALL

reference+token

Search Parameter Requirements (When Used Alone or in Combination):

patient (reference):
The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.
role (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.
status (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.

Condition

Conformance Expectation: SHOULD

Resource Specific Documentation:

For Encounter Diagnosis use the US Core Condition Encounter Diagnosis Profile.

When Condition.category is "encounter-diagnosis" the encounter, SHOULD be referenced in Condition.encounter.

For Problems and Health Concerns use the US Core Condition Problems and Health Concerns Profile.

When Condition.category is a "problems-list-item", the `Condition.clinicalStatus SHOULD be present.

There is no single element in Condition that represents the date of diagnosis. It may be the assertedDate Extension, Condition.onsetDateTime, or Condition.recordedDate.

Although all three are marked as must support, the server is not required to support all.

A server SHALL support Condition.recordedDate.

A server SHALL support at least one of the assertedDate Extension and Condition.onsetDateTime. A server may support both, which means they support all three elements.

The client application SHALL support all three elements.

See the US Core General Guidance page for Searching Using lastUpdated. Updates to Condition.meta.lastUpdated SHOULD reflect:

New problems and health concerns

Changes in the clinical status or verifications status of problems or health concern

Supported Profiles:

SHALL support: US Core Condition Encounter Diagnosis Profile
SHALL support: US Core Condition Problems and Health Concerns Profile

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Client SHALL be capable of fetching a Condition resource using: GET [base]/Condition/[id]
A Client SHOULD be capable of supporting the following _revincludes: Provenance:target - GET [base]/Condition?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance	Parameter	Type
SHALL	patient	reference

Conformance

Parameter

Type

SHALL

reference

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHOULD	patient+ category+ encounter	reference+token+reference
SHOULD	patient+ recorded-date	reference+date
SHOULD	patient+ _lastUpdated	reference+date
SHOULD	patient+ category+ clinical-status	reference+token+token
SHALL	patient+ category	reference+token
SHOULD	patient+ onset-date	reference+date
SHOULD	patient+ code	reference+token
SHOULD	patient+ clinical-status	reference+token
SHOULD	patient+ asserted-date	reference+date
SHOULD	patient+ abatement-date	reference+date

Conformance

Parameter Combination

Types

SHOULD

patient+ category+ encounter

reference+token+reference

SHOULD

patient+ recorded-date

reference+date

SHOULD

patient+ _lastUpdated

reference+date

SHOULD

patient+ category+ clinical-status

reference+token+token

SHALL

reference+token

SHOULD

patient+ onset-date

reference+date

SHOULD

reference+token

SHOULD

patient+ clinical-status

reference+token

SHOULD

patient+ asserted-date

reference+date

SHOULD

patient+ abatement-date

reference+date

Search Parameter Requirements (When Used Alone or in Combination):

abatement-date (date):
A client SHALL provide a value precise to the second + time offset.

A server SHALL support a value precise to the second + time offset.
asserted-date (date):
A client SHALL provide a value precise to the second + time offset.

A server SHALL support a value precise to the second + time offset.
category (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.
clinical-status (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.
code (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.
encounter (reference):
The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.
onset-date (date):
A client SHALL provide a value precise to the second + time offset.

A server SHALL support a value precise to the second + time offset.
patient (reference):
The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.
recorded-date (date):
A client SHALL provide a value precise to the second + time offset.

A server SHALL support a value precise to the second + time offset.
_lastUpdated (date):
A server SHALL document the types of changes that can be detected using this parameter.

A client SHALL provide a value precise to the second + time offset.

A server SHALL support a value precise to the second + time offset.

Coverage

Conformance Expectation: SHOULD

Supported Profiles:

SHALL support: US Core Coverage Profile

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Client SHALL be capable of fetching a Coverage resource using: GET [base]/Coverage/[id]
A Client SHOULD be capable of supporting the following _revincludes: Provenance:target - GET [base]/Coverage?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance	Parameter	Type
SHALL	patient	reference

Conformance

Parameter

Type

SHALL

reference

Search Parameter Requirements (When Used Alone or in Combination):

patient (reference):
The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.

Device

Conformance Expectation: SHOULD

Resource Specific Documentation:

Implantable medical devices that have UDI information SHALL represent the UDI code in Device.udiCarrier.carrierHRF.

All of the five UDI-PI elements that are present in the UDI code SHALL be represented in the corresponding US Core Implantable Device Profile element.

UDI may not be present in all scenarios such as historical implantable devices, patient reported implant information, payer reported devices, or improperly documented implants. If UDI is not present and the manufacturer and/or model number information is available, they SHOULD be included to support historical reports of implantable medical devices as follows:

manufacturer -> Device.manufacturer
model -> Device.model

Servers SHOULD support query by Device.type to allow clients to request the patient's devices by a specific type. Note: The Device.type is too granular to differentiate implantable vs. non-implantable devices.

Supported Profiles:

SHALL support: US Core Implantable Device Profile

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Client SHALL be capable of fetching a Device resource using: GET [base]/Device/[id]
A Client SHOULD be capable of supporting the following _revincludes: Provenance:target - GET [base]/Device?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance	Parameter	Type
SHALL	patient	reference

Conformance

Parameter

Type

SHALL

reference

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHOULD	patient+ status	reference+token
SHOULD	patient+ type	reference+token

Conformance

Parameter Combination

Types

SHOULD

reference+token

SHOULD

patient+ type

reference+token

Search Parameter Requirements (When Used Alone or in Combination):

patient (reference):
The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.
status (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.
type (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.

DiagnosticReport

Conformance Expectation: SHOULD

Resource Specific Documentation:

For laboratory result reports use the US Core DiagnosticReport Profile for Laboratory Results Reporting Profile.

Updates to .meta.lastUpdated SHOULD reflect:

New laboratory reports

Changes in the status of laboratory reports including events that trigger the same status (e.g., amended → amended).

For imaging and non-laboratory clinical test result reports use the US Core DiagnosticReport Profile for Report and Note Exchange Profile.

Diagnostic imaging results in visual images requiring interpretation and clinical test results/reports may also reference images as part of the report. There is no single approach for accessing imaging studies alongside clinical data using a single authorization flow to give patients and providers access to the images.

The DiagnosticReport.media.link element SHOULD be used to support links to various patient-friendly content, such as jpg images of x-rays (see the DiagnosticReport Chest X-ray Report Example).

The DiagnosticReport.imagingStudy element SHOULD be used to support exchange with systems that can view DICOM (Digital Imaging and Communications in Medicine) studies, series, and SOP (Service-Object Pair) instances referenced in the [ImagingStudy] resource.

Alternatively, systems can use business identifiers such as accession numbers in the identifier element to access the source images from external sources.

The DiagnosticRequest.basedOn element connects the DiagnosticReport to the originating order in the EHR. Systems that initiate the lab order SHOULD use this element when reporting the results.

Supported Profiles:

SHALL support: US Core DiagnosticReport Profile for Report and Note exchange
SHALL support: US Core DiagnosticReport Profile for Laboratory Results Reporting

Profile Interaction Summary:

SHALL support create^†, search-type, read.
SHOULD support vread, history-instance.
MAY support update, patch, delete, history-type.

create^†
This conformance expectation applies only to the US Core DiagnosticReport Profile for Report and Note exchange profile. The conformance expectation for the US Core DiagnosticReport Profile for Laboratory Results Reporting is MAY.

Fetch and Search Criteria:

A Client SHALL be capable of fetching a DiagnosticReport resource using: GET [base]/DiagnosticReport/[id]
A Client SHOULD be capable of supporting the following _revincludes: Provenance:target - GET [base]/DiagnosticReport?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance	Parameter	Type
SHALL	patient	reference

Conformance

Parameter

Type

SHALL

reference

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHOULD	patient+ category+ _lastUpdated	reference+token+date
SHOULD	patient+ status	reference+token
SHALL	patient+ category	reference+token
SHALL	patient+ category+ date	reference+token+date
SHALL	patient+ code	reference+token
SHOULD	patient+ code+ date	reference+token+date

Conformance

Parameter Combination

Types

SHOULD

patient+ category+ _lastUpdated

reference+token+date

SHOULD

reference+token

SHALL

reference+token

SHALL

reference+token+date

SHALL

reference+token

SHOULD

patient+ code+ date

reference+token+date

Search Parameter Requirements (When Used Alone or in Combination):

category (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.
code (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.
date (date):
A client SHALL provide a value precise to the second + time offset.

A server SHALL support a value precise to the second + time offset.
_lastUpdated (date):
A server SHALL document the types of changes that can be detected using this parameter.

A client SHALL provide a value precise to the second + time offset.

A server SHALL support a value precise to the second + time offset.
patient (reference):
The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.
status (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.

DocumentReference

Conformance Expectation: SHOULD

Resource Specific Documentation:

For Advance Directive Information (ADI) documents use the US Core ADI DocumentReference Profile.

For other clinical documents use the US Core DiagnosticReport Profile for Report and Note Exchange.

See the Clinical Notes page for important definitions, requirements, and guidance on creating, using, and sharing Clinical Notes.

The DocumentReference.type binding Must Support at a minimum the 10 Common Clinical Notes and may extend to the full US Core DocumentReference Type Value Set

The DocumentReference resources can represent the referenced content using either an address where the document can be retrieved using DocumentReference.attachment.url or the content as inline base64 encoded data using DocumentReference.attachment.data.

Although both are marked as must support, the server system is not required to support an address, and inline base64 encoded data, but SHALL support at least one of these elements.

The client application SHALL support both elements.

The content.attachment.url may refer to a FHIR Binary Resource (i.e. [base]/Binary/[id]), FHIR Document Bundle (i.e [base]/Bundle/[id] or another endpoint.

If there are multiple DocumentReference.content element repetitions, these SHALL all represent the same document in different format or attachment metadata. The content element SHALL NOT contain different versions of the same content. For version handling use multiple DocumentReferences with DocumentReference.relatesTo

Every DocumentReference must have a responsible Organization. The organization responsible for the DocumentReference SHALL be present either in DocumentReference.custodian or accessible in the Provenance resource targeting the DocumentReference using Provenance.agent.who or Provenance.agent.onBehalfOf.

Supported Profiles:

SHALL support: US Core DocumentReference Profile
SHALL support: US Core ADI DocumentReference Profile

Profile Interaction Summary:

SHALL support create, search-type, read.
SHOULD support vread, history-instance.
MAY support update, patch, delete, history-type.

Operation Summary:

SHOULD support the $docref operation
A client SHOULD be capable of transacting a $docref operation and capable of receiving at least a reference to a generated CCD document, and MAY be able to receive other document types, if available. SHOULD be capable of receiving documents as included resources in response to the operation.

GET [base]/DocumentReference/$docref?patient=[id]

Fetch and Search Criteria:

A Client SHALL be capable of fetching a DocumentReference resource using: GET [base]/DocumentReference/[id]
A Client SHOULD be capable of supporting the following _revincludes: Provenance:target - GET [base]/DocumentReference?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance	Parameter	Type
SHALL	_id	token
SHALL	patient	reference

Conformance

Parameter

Type

SHALL

_id

token

SHALL

reference

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHOULD	patient+ status	reference+token
SHALL	patient+ category	reference+token
SHALL	patient+ category+ date	reference+token+date
SHOULD	patient+ type+ period	reference+token+date
SHALL	patient+ type	reference+token

Conformance

Parameter Combination

Types

SHOULD

reference+token

SHALL

reference+token

SHALL

reference+token+date

SHOULD

patient+ type+ period

reference+token+date

SHALL

patient+ type

reference+token

Search Parameter Requirements (When Used Alone or in Combination):

category (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.
date (date):
A client SHALL provide a value precise to the second + time offset.

A server SHALL support a value precise to the second + time offset.
patient (reference):
The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.
period (date):
A client SHALL provide a value precise to the second + time offset.

A server SHALL support a value precise to the second + time offset.
status (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.
type (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.

Encounter

Conformance Expectation: SHOULD

Resource Specific Documentation:

The Encounter resource can represent a reason using either a code with Encounter.reasonCode, or a reference with Encounter.reasonReference to Condition or other resource.

Although both are marked as must support, the server systems are not required to support both a code and a reference, but they SHALL support at least one of these elements.

The client application SHALL support both elements.

if Encounter.reasonReference references an Observation, it SHOULD conform to a US Core Observation if applicable. (for example, a laboratory result should conform to the US Core Laboratory Result Observation Profile)

The location address can be represented by either by the Location referenced by Encounter.location.location or indirectly through the Organization referenced by Encounter.serviceProvider.

Although both are marked as must support, the server systems are not required to support both Encounter.location.location and Encounter.serviceProvider, but they SHALL support at least one of these elements.

The client application SHALL support both elements.

If the event facility/location differs from the Encounter.location, systems SHOULD reference it directly:

Servers can use the US Core Interpreter Needed Extension on this profile or the [US Core Patient Profile] to communicate whether a patient needs an interpreter. Although the extension is marked as an Additional USCDI Requirements on both US Core Patient and US Core Encounter Profiles, the certifying Server system is not required to support the extension on both profiles, but SHALL support the extension on at least one. The certifying Client application SHALL support the extension on both profiles.

Systems SHOULD designate the patient's preferred language in the Patient.communication.preferred element.

Updates to .meta.lastUpdated SHOULD reflect:

New encounters/visits

Changes in the status of encounters, including events that trigger the same status (e.g., in-progress → in-progress). These status changes correspond to events that can initiate [HL7 V2] ADT messages.

Supported Profiles:

SHALL support: US Core Encounter Profile

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Client SHALL be capable of fetching a Encounter resource using: GET [base]/Encounter/[id]
A Client SHOULD be capable of supporting the following _revincludes: Provenance:target - GET [base]/Encounter?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance	Parameter	Type
SHALL	_id	token
SHOULD	identifier	token
SHALL	patient	reference

Conformance

Parameter

Type

SHALL

_id

token

SHOULD

identifier

token

SHALL

reference

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHALL	date+ patient	date+reference
SHOULD	patient+ _lastUpdated	reference+date
SHOULD	patient+ status	reference+token
SHOULD	patient+ type	reference+token
SHOULD	patient+ location	reference+reference
SHOULD	patient+ discharge-disposition	reference+token
SHOULD	class+ patient	token+reference

Conformance

Parameter Combination

Types

SHALL

date+ patient

date+reference

SHOULD

patient+ _lastUpdated

reference+date

SHOULD

reference+token

SHOULD

patient+ type

reference+token

SHOULD

patient+ location

reference+reference

SHOULD

patient+ discharge-disposition

reference+token

SHOULD

class+ patient

token+reference

Search Parameter Requirements (When Used Alone or in Combination):

class (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.
date (date):
A client SHALL provide a value precise to the second + time offset.

A server SHALL support a value precise to the second + time offset.
_lastUpdated (date):
A server SHALL document the types of changes that can be detected using this parameter.

A client SHALL provide a value precise to the second + time offset.

A server SHALL support a value precise to the second + time offset.
discharge-disposition (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.
identifier (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.
location (reference):
The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.
patient (reference):
The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.
status (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.
type (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.

Endpoint

Conformance Expectation: SHOULD

Resource Specific Documentation:

The Media Resource is a Must Support referenced resource when using the US Core PractitionerRole Profile.

Profile Interaction Summary:

SHOULD support read, vread.
MAY support create, search-type, update, patch, delete, history-instance, history-type.

Fetch and Search Criteria:

A Client SHOULD be capable of fetching a Endpoint resource using: GET [base]/Endpoint/[id]

Goal

Conformance Expectation: SHOULD

Resource Specific Documentation:

Although both Goal.startDate and Goal.target.dueDate are marked as must support, the server system is not required to support both, but SHALL support at least one of these elements. The client application SHALL support both elements.

Supported Profiles:

SHALL support: US Core Goal Profile

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Client SHALL be capable of fetching a Goal resource using: GET [base]/Goal/[id]
A Client SHOULD be capable of supporting the following _revincludes: Provenance:target - GET [base]/Goal?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance	Parameter	Type
SHALL	patient	reference

Conformance

Parameter

Type

SHALL

reference

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHOULD	patient+ lifecycle-status	reference+token
SHOULD	patient+ description	reference+token
SHOULD	patient+ target-date	reference+date

Conformance

Parameter Combination

Types

SHOULD

patient+ lifecycle-status

reference+token

SHOULD

patient+ description

reference+token

SHOULD

patient+ target-date

reference+date

Search Parameter Requirements (When Used Alone or in Combination):

lifecycle-status (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.
patient (reference):
The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.
target-date (date):
A client SHALL provide a value precise to the day.

A server SHALL support a value a value precise to the day.

HealthcareService

Conformance Expectation: MAY

Resource Specific Documentation:

The HealthcareService Resource is a referenced resource when using the US Core PractitionerRole Profile and subject to constraint us-core-13: "SHALL have a practitioner, an organization, a healthcare service, or a location."

Profile Interaction Summary:

SHOULD support read, vread.
MAY support create, search-type, update, patch, delete, history-instance, history-type.

Fetch and Search Criteria:

A Client SHOULD be capable of fetching a HealthcareService resource using: GET [base]/HealthcareService/[id]

Immunization

Conformance Expectation: SHOULD

Resource Specific Documentation:

Based upon the ASTP U.S. Core Data for Interoperability (USCDI) requirements, CVX vaccine codes are required and the NDC vaccine codes SHOULD be supported as an additional code.

Supported Profiles:

SHALL support: US Core Immunization Profile

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Client SHALL be capable of fetching a Immunization resource using: GET [base]/Immunization/[id]
A Client SHOULD be capable of supporting the following _revincludes: Provenance:target - GET [base]/Immunization?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance	Parameter	Type
SHALL	patient	reference

Conformance

Parameter

Type

SHALL

reference

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHOULD	patient+ status	reference+token
SHOULD	patient+ date	reference+date

Conformance

Parameter Combination

Types

SHOULD

reference+token

SHOULD

patient+ date

reference+date

Search Parameter Requirements (When Used Alone or in Combination):

date (date):
A client SHALL provide a value precise to the second + time offset.

A server SHALL support a value precise to the second + time offset.
patient (reference):
The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.
status (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.

Location

Conformance Expectation: SHOULD

Resource Specific Documentation:

Systems SHOULD follow the Project US@ Technical Specification for Patient Addresses Final Version 1.0 as the standard style guide for Location.address.line and Location.address.city.

Supported Profiles:

SHALL support: US Core Location Profile

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Client SHALL be capable of fetching a Location resource using: GET [base]/Location/[id]

Search Parameter Summary:

Conformance	Parameter	Type
SHALL	address	string
SHOULD	address-city	string
SHOULD	address-postalcode	string
SHOULD	address-state	string
SHALL	name	string

Conformance

Parameter

Type

SHALL

address

string

SHOULD

address-city

string

SHOULD

address-postalcode

string

SHOULD

address-state

string

SHALL

string

Media

Conformance Expectation: SHOULD

Resource Specific Documentation:

The Media Resource is a Must Support referenced resource when using the US Core DiagnosticReport Profile for Report and Note Exchange.

Profile Interaction Summary:

SHOULD support read, vread.
MAY support create, search-type, update, patch, delete, history-instance, history-type.

Fetch and Search Criteria:

A Client SHOULD be capable of fetching a Media resource using: GET [base]/Media/[id]

Medication

Conformance Expectation: SHOULD

Resource Specific Documentation:

The MedicationRequest resource can represent a medication, using an external reference to a Medication resource. If an external Medication Resource is used in a MedicationRequest, then the READ SHALL be supported.

Supported Profiles:

SHALL support: US Core Medication Profile

Profile Interaction Summary:

SHALL support read.
SHOULD support vread, history-instance.
MAY support create, search-type, update, patch, delete, history-type.

Fetch and Search Criteria:

A Client SHALL be capable of fetching a Medication resource using: GET [base]/Medication/[id]

MedicationDispense

Conformance Expectation: SHOULD

Resource Specific Documentation:

This Profile can represent a medication using a code or reference a Medication resource.

The Server systems are not required to support both a code and a reference, but SHALL support at least one of these methods.

The Client application SHALL support all methods.

Systems that primarily rely on NDC codes instead of RxNorm to represent medications can use the National Library of Medicine's (NLM) NDC to RxNorm mappings to aid in additional codings.

When referencing a Medication resource in .medicationReference, the resource may be contained or an external resource. If an external reference to a Medication resource is used, the Server SHALL support the _include parameter for searching this element.

Supported Profiles:

SHALL support: US Core MedicationDispense Profile

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Client SHALL be capable of fetching a MedicationDispense resource using: GET [base]/MedicationDispense/[id]
A Client SHOULD be capable of supporting the following _includes:
- MedicationDispense:medication: GET [base]/MedicationDispense?[parameter=value]&_include=MedicationDispense:medication
A Client SHOULD be capable of supporting the following _revincludes: Provenance:target - GET [base]/MedicationDispense?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance	Parameter	Type
SHALL	patient	reference

Conformance

Parameter

Type

SHALL

reference

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHOULD	patient+ status+ type	reference+token+token
SHOULD	patient+ status	reference+token

Conformance

Parameter Combination

Types

SHOULD

patient+ status+ type

reference+token+token

SHOULD

reference+token

Search Parameter Requirements (When Used Alone or in Combination):

patient (reference):
The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.
status (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.
type (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.

MedicationRequest

Conformance Expectation: SHOULD

Resource Specific Documentation:

This Profile can represent a medication using a code or reference a Medication resource.

The Server systems are not required to support both a code and a reference, but SHALL support at least one of these methods.

The Client application SHALL support all methods.

Systems that primarily rely on NDC codes instead of RxNorm to represent medications can use the National Library of Medicine's (NLM) NDC to RxNorm mappings to aid in additional codings.

When referencing a Medication resource in .medicationReference, the resource may be contained or an external resource. If an external reference to a Medication resource is used, the Server SHALL support the _include parameter for searching this element.

The MedicationRequest resource can represent that information is from a secondary source using either a boolean flag or reference in MedicationRequest.reportedBoolean, or a reference using MedicationRequest.reportedReference to Practitioner or other resource.

Although both are marked as must support, the server systems are not required to support both a boolean and a reference, but SHALL choose to support at least one of these elements.

The client application SHALL support both elements.

When recording “self-prescribed” medication, requester SHOULD be used to indicate the Patient or RelatedPerson as the prescriber. (See the Medication List section for guidance on accessing a patient medications including over the counter (OTC) medication and other substances taken for medical and recreational use.)

The MedicationRequest resource can communicate the reason or indication for treatment using either a code in MedicationRequest.reasonCode or a reference using MedicationRequest.reasonReference.

Although both MedicationRequest.reasonCode and MedicationRequest.reasonReference are marked as Additional USCDI Requirements. The certifying server system is not required to support both but SHALL support at least one of these elements. The certifying client application SHALL support both elements.

when using MedicationRequest.reasonReference:

Servers SHALL support at least one target resource in MedicationRequest.reasonReference. Clients SHALL support all target resources.

The referenced resources SHOULD be a US Core Profile as documented in Referencing US Core Profiles.

Supported Profiles:

SHALL support: US Core MedicationRequest Profile

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Client SHALL be capable of fetching a MedicationRequest resource using: GET [base]/MedicationRequest/[id]
A Client SHOULD be capable of supporting the following _includes:
- MedicationRequest:medication: GET [base]/MedicationRequest?[parameter=value]&_include=MedicationRequest:medication
A Client SHOULD be capable of supporting the following _revincludes: Provenance:target - GET [base]/MedicationRequest?[parameter=value]&_revinclude=Provenance:target

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHOULD	patient+ intent+ encounter	reference+token+reference
SHALL	patient+ intent+ status	reference+token+token
SHOULD	patient+ intent+ authoredon	reference+token+date
SHALL	patient+ intent	reference+token

Conformance

Parameter Combination

Types

SHOULD

patient+ intent+ encounter

reference+token+reference

SHALL

patient+ intent+ status

reference+token+token

SHOULD

patient+ intent+ authoredon

reference+token+date

SHALL

patient+ intent

reference+token

Search Parameter Requirements (When Used Alone or in Combination):

authoredon (date):
A client SHALL provide a value precise to the second + time offset.

A server SHALL support a value precise to the second + time offset.
encounter (reference):
The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.
intent (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.
patient (reference):
The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.
status (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.

Observation

Conformance Expectation: SHOULD

Resource Specific Documentation:

Systems SHOULD support Observation.effectivePeriod to accurately represent tests that are collected over a period of time (for example, a 24-Hour Urine Collection test).

An Observation without a value, SHALL include a reason why the data is absent unless there are component observations, or references to other Observations that are grouped within it

Systems that never provide an observation without a value are not required to support Observation.dataAbsentReason

An Observation.component without a value, SHALL include a reason why the data is absent.

Systems that never provide an component observation without a component value are not required to support Observation.component.dataAbsentReason.

There are multiple Observation profiles. Refer to the specific profile page for profile specific conformance rules and guidance

Supported Profiles:

SHALL support: US Core Observation ADI Documentation Profile
SHALL support: US Core Laboratory Result Observation Profile
SHALL support: US Core Observation Pregnancy Status Profile
SHALL support: US Core Observation Pregnancy Intent Profile
SHALL support: US Core Observation Occupation Profile
SHALL support: US Core Respiratory Rate Profile
SHALL support: US Core Simple Observation Profile
SHALL support: US Core Treatment Intervention Preference Profile
SHALL support: US Core Care Experience Preference Profile
SHALL support: US Core Heart Rate Profile
SHALL support: US Core Body Temperature Profile
SHALL support: US Core Pediatric Weight for Height Observation Profile
SHALL support: US Core Pulse Oximetry Profile
SHALL support: US Core Smoking Status Observation Profile
MAY support: US Core Observation Sexual Orientation Profile
SHALL support: US Core Head Circumference Profile
SHALL support: US Core Body Height Profile
SHALL support: US Core BMI Profile
SHALL support: US Core Observation Screening Assessment Profile
SHALL support: US Core Average Blood Pressure Profile
SHALL support: US Core Blood Pressure Profile
SHALL support: US Core Observation Clinical Result Profile
SHALL support: US Core Pediatric BMI for Age Observation Profile
SHALL support: US Core Pediatric Head Occipital Frontal Circumference Percentile Profile
SHALL support: US Core Body Weight Profile
SHALL support: US Core Vital Signs Profile

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Client SHALL be capable of fetching a Observation resource using: GET [base]/Observation/[id]
A Client SHOULD be capable of supporting the following _revincludes: Provenance:target - GET [base]/Observation?[parameter=value]&_revinclude=Provenance:target

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHOULD	patient+ category+ _lastUpdated	reference+token+date
SHALL	patient+ category	reference+token
SHOULD	patient+ category+ status	reference+token+token
SHALL	patient+ category+ date	reference+token+date
SHALL	patient+ code	reference+token
SHOULD	patient+ code+ date	reference+token+date

Conformance

Parameter Combination

Types

SHOULD

patient+ category+ _lastUpdated

reference+token+date

SHALL

reference+token

SHOULD

patient+ category+ status

reference+token+token

SHALL

reference+token+date

SHALL

reference+token

SHOULD

patient+ code+ date

reference+token+date

Search Parameter Requirements (When Used Alone or in Combination):

category (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.
code (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.
date (date):
A client SHALL provide a value precise to the second + time offset.

A server SHALL support a value precise to the second + time offset.
_lastUpdated (date):
A server SHALL document the types of changes that can be detected using this parameter.

A client SHALL provide a value precise to the second + time offset.

A server SHALL support a value precise to the second + time offset.
patient (reference):
The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.
status (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.

Organization

Conformance Expectation: SHOULD

Resource Specific Documentation:

Systems SHALL support National Provider Identifier (NPI) for organizations and SHOULD support Clinical Laboratory Improvement Amendments (CLIA) and the National Association of Insurance Commissioners NAIC Company code (sometimes called "NAIC Number" or "cocode") for Organization.Identifier.

Systems SHOULD follow the Project US@ Technical Specification for Patient Addresses Final Version 1.0 as the standard style guide for Organization.address.line and Organization.address.city.

Supported Profiles:

SHALL support: US Core Organization Profile

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Client SHALL be capable of fetching a Organization resource using: GET [base]/Organization/[id]

Search Parameter Summary:

Conformance	Parameter	Type
SHALL	address	string
SHALL	name	string

Conformance

Parameter

Type

SHALL

address

string

SHALL

string

Patient

Conformance Expectation: SHOULD

Resource Specific Documentation:

The Patient's Social Security Numbers SHOULD NOT be used as a patient identifier in Patient.identifier.value.

The Complex Extensions for Race and Ethnicity allow for one or more codes of which: Must Support at least one category code from the OMB Race and Ethnicity Category Value Sets that draw from the Race & Ethnicity - CDC (CDCREC] code system.

MAY include additional codes from the detailed ethnicity and detailed race value sets drawn from the Race & Ethnicity - CDC (CDCREC) code system

SHALL include a text description

Although Patient.deceased[x] is marked as 헔헗헗헜헧헜헢헡헔헟 헨헦헖헗헜, certifying systems are not required to support both choices, but SHALL support at least Patient.deceasedDateTime.

Servers can use the US Core Interpreter Needed Extension on this profile or the US Core Encounter Profile to communicate whether a patient needs an interpreter. Although the extension is marked as an Additional USCDI Requirement on both US Core Patient and US Core Encounter Profiles, the certifying Server system is not required to support the extension on both profiles but SHALL support the extension on at least one. The certifying Client application SHALL support the extension on both profiles.

Systems SHOULD designate the patient's preferred language in the Patient.communication.preferred element.

Certifying systems SHALL and non-certifying systems SHOULD follow the Project US@ Technical Specification for Patient Addresses Final Version 1.0 as the standard style guide for Patient.address.line and Patient.address.city for new and updated records.

Supported Profiles:

SHALL support: US Core Patient Profile

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Client SHALL be capable of fetching a Patient resource using: GET [base]/Patient/[id]
A Client SHOULD be capable of supporting the following _revincludes: Provenance:target - GET [base]/Patient?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance	Parameter	Type
SHALL	_id	token
SHALL	identifier	token
SHALL	name	string

Conformance

Parameter

Type

SHALL

_id

token

SHALL

identifier

token

SHALL

string

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHALL	birthdate+ name	date+string
SHOULD	death-date+ family	date+string
SHOULD	birthdate+ family	date+string

Conformance

Parameter Combination

Types

SHALL

birthdate+ name

date+string

SHOULD

death-date+ family

date+string

SHOULD

birthdate+ family

date+string

Search Parameter Requirements (When Used Alone or in Combination):

birthdate (date):
A client SHALL provide a value precise to the day.

A server SHALL support a value a value precise to the day.
death-date (date):
A client SHALL provide a value precise to the day.

A server SHALL support a value a value precise to the day.
family (string):
A server SHALL support a value precise to the day.
identifier (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.

Practitioner

Conformance Expectation: SHOULD

Resource Specific Documentation:

Servers that support only US Core Practitioner Profile and do not support the US Core PractitionerRole Profile SHALL provide implementation specific guidance how to access a provider’s location and contact information using only the Practitioner resource.

Although Practitioner.address is marked as Must Support, the server system is not required to support it if they support the US Core PractitionerRole Profile, but SHALL support it if they do not support the US Core PractitionerRole Profile. The client application SHALL support both.

To balance the privacy of healthcare workers with the patient's right to access information. Only professional/work contact information about the practitioner SHOULD be available to the patient (such as a work address or office telephone number).

Systems SHOULD follow the Project US@ Technical Specification for Patient Addresses Final Version 1.0 as the standard style guide for Practitioner.address.line and Practitioner.address.city.

Supported Profiles:

SHALL support: US Core Practitioner Profile

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Client SHALL be capable of fetching a Practitioner resource using: GET [base]/Practitioner/[id]

Search Parameter Summary:

Conformance	Parameter	Type
SHOULD	_id	token
SHALL	identifier	token
SHALL	name	string

Conformance

Parameter

Type

SHOULD

_id

token

SHALL

identifier

token

SHALL

string

Search Parameter Requirements (When Used Alone or in Combination):

identifier (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.

PractitionerRole

Conformance Expectation: SHOULD

Resource Specific Documentation:

Due to implementer feedback, some US Core Profiles reference the PractitionerRole resource instead of the US Core PractitionerRole Profile. However the US Core PractitionerRole Profile SHOULD be used as the default profile if referenced by another US Core profile.

Supported Profiles:

SHALL support: US Core PractitionerRole Profile

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Client SHALL be capable of fetching a PractitionerRole resource using: GET [base]/PractitionerRole/[id]
A Client SHOULD be capable of supporting the following _includes:
- PractitionerRole:endpoint: GET [base]/PractitionerRole?[parameter=value]&_include=PractitionerRole:endpoint
- PractitionerRole:practitioner: GET [base]/PractitionerRole?[parameter=value]&_include=PractitionerRole:practitioner

Search Parameter Summary:

Conformance	Parameter	Type
SHALL	practitioner	reference
SHALL	specialty	token

Conformance

Parameter

Type

SHALL

practitioner

reference

SHALL

specialty

token

Search Parameter Requirements (When Used Alone or in Combination):

practitioner (reference):
The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.
specialty (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.

Procedure

Conformance Expectation: SHOULD

Resource Specific Documentation:

Procedure codes can be taken from SNOMED-CT, CPT, HCPCS II, ICD-10-PCS, CDT. LOINC.

Only LOINC concepts that reflect actual procedures SHOULD be used

A procedure including an implantable device SHOULD use Procedure.focalDevice with a reference to the US Core Implantable Device Profile.

Servers and Clients SHALL support both US Core ServiceRequest and US Core Procedure Profiles for communicating the reason or justification for a referral as Additional USCDI Requirements. Typically, the reason or justification for a referral or consultation is communicated through Procedure.basedOn linking the Procedure to the US Core ServiceRequest Profile that includes either ServiceRequest.reasonCode or ServiceRequest.reasonReference. When the Procedure does not have an associated ServiceRequest, it is communicated through the US Core Procedure Profile's Procedure.reasonCode or Procedure.reasonReference. Depending on the procedure being documented, a server will select the appropriate Profile to use.

Although both Procedure.reasonCode and Procedure.reasonReference are marked as Additional USCDI Requirements. The certifying server system is not required to support both but SHALL support at least one of these elements. The certifying client application SHALL support both elements.

when using Procedure.reasonReference:

Servers SHALL support at least one target resource in Procedure.reasonReference. Clients SHALL support all target resources .

The referenced resources SHOULD be a US Core Profile.

Supported Profiles:

SHALL support: US Core Procedure Profile

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Client SHALL be capable of fetching a Procedure resource using: GET [base]/Procedure/[id]
A Client SHOULD be capable of supporting the following _revincludes: Provenance:target - GET [base]/Procedure?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance	Parameter	Type
SHALL	patient	reference

Conformance

Parameter

Type

SHALL

reference

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHOULD	patient+ status	reference+token
SHALL	patient+ date	reference+date
SHOULD	patient+ code+ date	reference+token+date

Conformance

Parameter Combination

Types

SHOULD

reference+token

SHALL

patient+ date

reference+date

SHOULD

patient+ code+ date

reference+token+date

Search Parameter Requirements (When Used Alone or in Combination):

code (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.
date (date):
A client SHALL provide a value precise to the second + time offset.

A server SHALL support a value precise to the second + time offset.
patient (reference):
The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.
status (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.

Provenance

Conformance Expectation: SHOULD

Resource Specific Documentation:

The US Core Provenance resource SHALL be supported for these US Core resources:

AllergyIntolerance

CarePlan

CareTeam

Condition

Coverage

Device

DiagnosticReport

DocumentReference

Encounter

Goal

Immunization

MedicationDispense

MedicationRequest

Observation

Patient

Procedure

QuestionnaireResponse

RelatedPerson

ServiceRequest

If a system receives a provider in Provenance.agent.who as free text they must capture who sent them the information as the organization. On request they SHALL provide this organization as the source and MAY include the free text provider.

Systems that need to know the activity has occurred SHOULD populate the activity.

Supported Profiles:

SHALL support: US Core Provenance Profile

Profile Interaction Summary:

SHALL support read.
SHOULD support vread, history-instance.
MAY support create, search-type, update, patch, delete, history-type.

Fetch and Search Criteria:

A Client SHALL be capable of fetching a Provenance resource using: GET [base]/Provenance/[id]

Questionnaire

Conformance Expectation: SHOULD

Resource Specific Documentation:

US Core defines two ways to represent the questions and responses to screening and assessment instruments:

Observation: US Core Observation Screening Assessment Profile

Questionnaire/QuestionnaireResponse: SDC Base Questionnaire/US Core QuestionnaireResponse Profile

US Core Servers SHALL support US Core Observation Screening Assessment Profile and SHOULD support the SDC Base Questionnaire Profile/US Core QuestionnaireResponse Profile

Supported Profiles:

SHALL support: SDC Base Questionnaire Profile

Profile Interaction Summary:

SHOULD support read, vread.
MAY support create, search-type, update, patch, delete, history-instance, history-type.

Fetch and Search Criteria:

A Client SHOULD be capable of fetching a Questionnaire resource using: GET [base]/Questionnaire/[id]

QuestionnaireResponse

Conformance Expectation: SHOULD

Resource Specific Documentation:

US Core defines two ways to represent the questions and responses to screening and assessment instruments:

Observation: US Core Observation Screening Assessment Profile

Questionnaire/QuestionnaireResponse: SDC Base Questionnaire/US Core QuestionnaireResponse Profile

US Core Servers SHALL support US Core Observation Screening Assessment Profile and SHOULD support the SDC Base Questionnaire Profile/US Core QuestionnaireResponse Profile

Supported Profiles:

SHALL support: US Core QuestionnaireResponse Profile

Profile Interaction Summary:

SHOULD support search-type, read, vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Client SHOULD be capable of fetching a QuestionnaireResponse resource using: GET [base]/QuestionnaireResponse/[id]
A Client SHOULD be capable of supporting the following _revincludes: Provenance:target - GET [base]/QuestionnaireResponse?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance	Parameter	Type
SHALL	_id	token
SHALL	patient	reference

Conformance

Parameter

Type

SHALL

_id

token

SHALL

reference

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHOULD	patient+ authored	reference+date
SHOULD	patient+ status	reference+token
SHOULD	patient+ questionnaire	reference+reference

Conformance

Parameter Combination

Types

SHOULD

patient+ authored

reference+date

SHOULD

reference+token

SHOULD

patient+ questionnaire

reference+reference

Search Parameter Requirements (When Used Alone or in Combination):

authored (date):
A client SHALL provide a value precise to the second + time offset.

A server SHALL support a value precise to the second + time offset.
patient (reference):
The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.
questionnaire (reference):
The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.
status (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.

RelatedPerson

Conformance Expectation: SHOULD

Resource Specific Documentation:

Systems SHOULD follow the Project US@ Technical Specification for Patient Addresses Final Version 1.0 as the standard style guide for RelatedPerson.address.line and RelatedPerson.address.city.

Supported Profiles:

SHALL support: US Core RelatedPerson Profile

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Client SHALL be capable of fetching a RelatedPerson resource using: GET [base]/RelatedPerson/[id]
A Client SHOULD be capable of supporting the following _revincludes: Provenance:target - GET [base]/RelatedPerson?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance	Parameter	Type
SHALL	_id	token
SHOULD	name	string
SHOULD	patient	reference

Conformance

Parameter

Type

SHALL

_id

token

SHOULD

string

SHOULD

reference

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHOULD	patient+ name	reference+string

Conformance

Parameter Combination

Types

SHOULD

patient+ name

reference+string

Search Parameter Requirements (When Used Alone or in Combination):

patient (reference):
The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.

ServiceRequest

Conformance Expectation: SHOULD

Resource Specific Documentation:

The Must Support ServiceRequest.category is bound, at a minimum, to the US Core ServiceRequest Category Codes, and other category codes can be used. API consumers can query by category when accessing patient information. For the USCDI Laboratory Order, Imaging Order, Clinical Test Order, and Procedure Order Data Elements, implementers SHOULD use the corresponding category codes listed in the table on the US Core ServiceRequest Profile page. For example, laboratory orders would have the category code "108252007" (Laboratory procedure).

The ServiceRequest.code value set is broad to accommodate a wide variety of use cases and SHOULD be constrained to a subset for a particular use case or domain. These value sets contain concepts that span many use cases and are not bound to any USCDI Data Element. However, the table on the US Core ServiceRequest Profile page identifies additional value set bindings for the USCDI Laboratory Order, Imaging Order and Clinical Test Order Data Elements. Implementers SHOULD conform to the binding strengths for each USCDI Order context listed in the table. For example, laboratory orders are extensibly bound to the LOINC Common Laboratory Orders Value Set. Note that the USCDI Class Procedure Order Data Element has no additional binding.

Servers and Clients SHALL support both US Core ServiceRequest and US Core Procedure Profiles for communicating the reason or justification for a referral as Additional USCDI Requirements. Typically, the reason or justification for a referral or consultation is communicated through Procedure.basedOn linking the Procedure to the US Core ServiceRequest Profile that includes either ServiceRequest.reasonCode or ServiceRequest.reasonReference. When the Procedure does not have an associated ServiceRequest, it is communicated through the US Core Procedure Profile's Procedure.reasonCode or Procedure.reasonReference. Depending on the procedure being documented, a server will select the appropriate Profile to use.

Although both ServiceRequest.reasonCode and ServiceRequest.reasonReference are marked as Additional USCDI Requirements, the certifying server system is not required to support both, but SHALL support at least one of these elements. The certifying client application SHALL support both elements.

when using ServiceRequest.reasonReference:

Servers SHALL support at least one target resource in ServiceRequest.reasonReference. Clients SHALL support all target resources.

The referenced resources SHOULD be a US Core Profile as documented in Referencing US Core Profiles.

Supported Profiles:

SHALL support: US Core ServiceRequest Profile

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Client SHALL be capable of fetching a ServiceRequest resource using: GET [base]/ServiceRequest/[id]
A Client SHOULD be capable of supporting the following _revincludes: Provenance:target - GET [base]/ServiceRequest?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance	Parameter	Type
SHALL	_id	token
SHALL	patient	reference

Conformance

Parameter

Type

SHALL

_id

token

SHALL

reference

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHOULD	patient+ status	reference+token
SHALL	patient+ category	reference+token
SHOULD	patient+ code+ authored	reference+token+date
SHALL	patient+ category+ authored	reference+token+date
SHALL	patient+ code	reference+token

Conformance

Parameter Combination

Types

SHOULD

reference+token

SHALL

reference+token

SHOULD

patient+ code+ authored

reference+token+date

SHALL

patient+ category+ authored

reference+token+date

SHALL

reference+token

Search Parameter Requirements (When Used Alone or in Combination):

authored (date):
A client SHALL provide a value precise to the second + time offset.

A server SHALL support a value precise to the second + time offset.
category (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.
code (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.
patient (reference):
The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.
status (token):
The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.

Specimen

Conformance Expectation: SHOULD

Resource Specific Documentation:

Although both Specimen.identifier and Specimen.accessionIdentifier are marked as Must Support, the server system is not required to support both, but SHALL support at least one of these elements. The client application SHALL support both.

Supported Profiles:

SHALL support: US Core Specimen Profile

Profile Interaction Summary:

SHALL support read.
SHOULD support vread, history-instance.
MAY support create, search-type, update, patch, delete, history-type.

Fetch and Search Criteria:

A Client SHALL be capable of fetching a Specimen resource using: GET [base]/Specimen/[id]

Search Parameter Summary:

Conformance	Parameter	Type
SHALL	_id	token
SHOULD	patient	reference

Conformance

Parameter

Type

SHALL

_id

token

SHOULD